@Enkidu93 reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @ddaspit)

src/ServiceToolkit/src/SIL.ServiceToolkit/Services/OutboxDeliveryService.cs line 29 at r1 (raw file):

            try
            {
                await subscription.WaitForChangeAsync(cancellationToken: stoppingToken);

Is there anywhere else this could happen (e.g., waiting for a new build revision)? Is it possible to make this solution more generic?

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @ddaspit and @pmachapman)

src/ServiceToolkit/src/SIL.ServiceToolkit/Services/OutboxDeliveryService.cs line 29 at r1 (raw file):

            try
            {
                await subscription.WaitForChangeAsync(cancellationToken: stoppingToken);

Also, it's unlikely to make a big difference, but I think #440 is perhaps still unaddressed. I wonder if it's worth fixing that problem here if it hasn't been fixed already.

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @ddaspit and @Enkidu93)

src/ServiceToolkit/src/SIL.ServiceToolkit/Services/OutboxDeliveryService.cs line 29 at r1 (raw file):

Unless mistaken, I don't think resuming change streams will help here as MongoSubscription.WaitForChangeAsync() opens a new stream anyway every time it is called. If the change stream fails due to connection timeout or cancellation, a new change stream will be opened when the loop iterates and WaitForChangeAsync is called again.

src/ServiceToolkit/src/SIL.ServiceToolkit/Services/OutboxDeliveryService.cs line 29 at r1 (raw file):

The key issue is when the error occurs in a background service. From my understanding of Serval,. and experiments locally, I couldn't see any other background services that would fail in this way when Mongo is temporarily down.

If the connection was to timeout in BuildService.GetNewerRevisionAsync(), then the API endpoint which called this method would fail, and the client would call it again. I think that is OK.

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @ddaspit)

src/ServiceToolkit/src/SIL.ServiceToolkit/Services/OutboxDeliveryService.cs line 29 at r1 (raw file):

Yeah, I do think it could be helpful if we used resume tokens, but that's a change that'd be internal to the data access code. We can tackle that separately.

src/ServiceToolkit/src/SIL.ServiceToolkit/Services/OutboxDeliveryService.cs line 29 at r1 (raw file):

OK, I see. Makes sense!

@ddaspit reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @pmachapman)

src/ServiceToolkit/src/SIL.ServiceToolkit/Services/OutboxDeliveryService.cs line 30 at r1 (raw file):

            {
                await subscription.WaitForChangeAsync(cancellationToken: stoppingToken);
                if (stoppingToken.IsCancellationRequested)

We should call ThrowIfCancellationRequested() here. This will make the behavior more consistent, i.e. we will log the cancellation in all cases.

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @ddaspit and @Enkidu93)

src/ServiceToolkit/src/SIL.ServiceToolkit/Services/OutboxDeliveryService.cs line 30 at r1 (raw file):

Done. Good idea - thank you!

@ddaspit reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @pmachapman)